TLS hardening

This document presents TLS and how to make it secure enough as of 2014 Spring. Of course all the information given here will rot with time. Protocols known as secure will be cracked and will be replaced with better versions. Fortunately we will see that there are ways to assess the current security of your setup, but this explains why you may have to read further from this document to get the up to date knowledge on TLS security. We will first introduce the TLS protocol and its underlying components: X.509 certificates, ciphers, and protocol versions. Next we will have a look at TLS hardening for web servers, and how to plug various vulnerabilities: CRIME, BREACH, BEAST, session renegotiation, Heartbleed, and others. We will finally see how the know-how acquired on hardening web servers can be used for other protocols and tools such as Dovecot, Sendmail, SquirrelMail, RoundCube, and OpenVPN. We assume you already maintain services that use TLS, and have basic TCP/IP network knowledge. Some information will also be useful for the application developer. 1 An introduction to TLS TLS stands for Transport Layer Security. It is an encryption and authentication layer that fits between transport and application level in the TCP/IP network stack. It got specified by IETF in 1999 as an enhancement over Netscape’s Secure Socket Layer (SSL), which is why we often see the SSL term used instead of TLS. TLS is easy to add on top of any TCP service, and this is why it grown so popular, and it became available for many protocols. For instance, HTTP can be used over TLS, using well-known https:// URL. It works the same way for SMTP(S), IMAP(S), POP(S), LDAP(S), and so on. 1.1 X.509 certificates The main goal of TLS is enforcing confidentiality and integrity. This cannot happen if the remote peer is not properly authenticated: who cares about having a secure channel if we do not know who we are speaking to? Attacks where an intruder slips between the two legitimate parties are known as Man In The Middle (MITM or MiM) attacks. In such a setup, a secure channel exists between one legitimate party and the intruder, and there is another secure channel between the intruder and the second legitimate party. The legitimate parties talk to each others, and the intruder sees all the traffic. TLS attempts to authenticate the remote party using a Public Key Infrastructure (PKI). The idea is to use asymmetric cryptography, where each party has a private key capable of performing cryptographic signatures, and a public key, which can be used to verify a signature done by the associated private key. If a remote party is able to produce a public key validated signature for a nonce it was given, that proves it has the private key. ∗Reprinted with permission